A Multiple-User Software 
Development Unit 


Microcomputer software development is 
becoming, more and more, a team effort. 
And, as with any team-oriented project, 
there are problems of communication, 
keeping current on the status of each ele- 
ment in the project, and efficiently inte- 
grating the individual elements into a 
finished product. 

The new Tektronix 8560 Multi-User Soft- 
ware Development Unit is a team-oriented 
design tool. Accommodating up to eight 
workstations simultaneously, the 8560 pro- 
vides a powerful, flexible solution to soft- 
ware development problems. The 8560, 


teamed up with the Tektronix 8540 Integra- 


tion Unit or the 8550 Microcomputer De- 
velopment Lab’, lets you accomplish every 


Figure 1. The Tektronix 8560 Multi-User Software Development Unit (lower left) accomodates 
up to eight workstations, including multiple 8540 Integration Units and line printers. 


phase of software development, from in- 
itial design to hardware/software integra- 
tion, effectively and efficiently. (The 8540 
Integration Unit is discussed in an article 
commencing on page 9 of this issue.) 


Hardware overview 

The 8560 uses a multiple-processor ar- 
chitecture (see figure 2). The LSI 11/23 
main processor executes the operating 
system, assemblers, compilers, editors, 
and utility programs. A Z80-based disk 
controller handles both flexible and hard 
disk drives. The main processor makes 
high-level requests and the disk controller 
handles the details, such as seek optimiza- 
tion, locating the current track and sector, 
reading and writing blocks of data, and 
checking for errors. 

To relieve the main processor of the 
burden of handling all of the I/O traffic, an 
8088-based processor is provided for each 
group of four I/O ports. Over 90 percent of 
terminal I/O is off-loaded from the main 
processor. The I/O ports are configurable 
for RS-232 operation up to 9600 baud and 
RS-422 at 153.6 kilobaud. 

Memory in the standard system con- 
sists of 128 kilobytes of random access 
memory (RAM), 35.6 megabytes of hard 
disk storage, and one megabyte of flexible 
disk storage for transportable memory. 
Options expand RAM to 256 kilobytes, 
with additional hard disk capacity to be 
available at a later date. 


An advanced operating system 

The 8560 uses a powerful multitasking 
operating system called TNIX*. TNIX is a 
customized version of the popular UNIX** 
Version 7 operating system, optimized for 
microprocessor software development. 
UNIX is a well-established system and in- 
Cludes all of the tools essential for increas- 
ing programmer productivity—file manage- 
ment, program development, module build 
control, interuser communication, system 
maintenance, and text processing. 

The command language chosen for a 
software development system can be a 
major contributing factor to software pro- 
ductivity. A well-designed command 
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* TNIX is a trademark of Tektronix, Inc. 
**UNIX is a trademark of Bell Laboratories, 
Inc. 


LS1-11/23 on M1220 
PROCESSOR on... INTERFACE 


8560 SYSTEM BUS 


1.2 M BYTE 35.6 M BYTE 
POWER FRONT 

FLEXIBLE DISC HARD DISC 
DRIVE DRIVE SUPPLY PANEL 


LINE 
UTILITY PRINTER 


BOARD 


LINE 
PRINTER 


| 


MEMORY PROCESSOR PROCESSOR ADAPTER BOARD 
128 K BYTE 7 
OPTIONAL _ RS 232(TO 9600 BAUD) OR TERMINALS 
RS 422 (153.6 K BAUD) 


Figure 2. Block diagram of the 8560 Multi-User Software Development Unit. The multi- 
processor architecture optimizes performance of the various functions and permits tasks 


to be carried out in background mode. 


language should: be easy to learn, be flex- 
ible enough to be customized for individual 
needs, support powerful command files, 
and allow unambiguous task processing 
and information flow. 

Learning time can be minimized through 
the use of a menu-driven command lan- 
guage. However, once the language is 
mastered, the requirement to use menus 
can impede productivity (see figure 3). 

The TNIX menu-driven program (GUIDE) 
overcomes the necessity for users to re- 
spond to menu-driven queries. As a task 
proceeds, GUIDE prints out the com- 
mands being used, which helps to shorten 
learning time. However, one doesn’t have 
to use GUIDE for entering commands. 
Once the system is learned, the user can 
enter commands directly. Command 
menus on the 8560 also can be changed, 
allowing the user to customize the system. 

Command files allow multiple com- 
mands to be executed quickly and without 
typographical errors. Most systems allow 
parameters to be passed to a command 
file, thereby increasing their flexibility and 
ease of use. The 8560’s command lan- 
guage also allows variables to be defined 
by the user, and supports structured pro- 
gramming commands like “‘if...then... 
else’’", ‘for’ loops, “while”, ‘until’, and 
“case’’ statements. As an example, see 
figure 4. When these concepts are com- 
bined and used in a command file, users 
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Figure 3. This graph depicts the relative 
productivity achievable with a system that 
employs menu-driven commands, with a 
system that does not, and with one that 
uses a combination of menu and com- 
mand language. The 8560 uses the latter 
approach. 


grep ’.out’~ 


set “Is | 
do 

Iptr $i 
done 


Figure 4. The above command file checks 
the current directory for all files with the 
extension “.out” and outputs them to the 
lineprinter. 


can define or combine commands to per- 
form tasks that would normally require 
large, complex programs to accomplish. 

The 8560 also allows the output of one 
command to be passed as input to an- 
other command, without the use of tempo- 
rary “‘holding”’ files. This ‘‘pipe’’ construct 
allows information to be easily passed 
through the system while being processed 
by a series of commands. Large amounts 
of data can be quickly reduced to a man- 
ageable amount and output in a format 
allowing quick analysis by the user. All I/O 
devices are handled as ordinary files, 
thereby eliminating the special program- 
ming usually required to handle external 
devices. 


Multitasking increases productivity 

A multitasking system increases a soft- 
ware designer’s productivity by performing 
two or more tasks at the same time. With 
the 8560, time-consuming tasks, such as 
assemblies or compilation, can be execut- 
ed in ‘‘background’’ mode while the user 
is free to perform simpler tasks, such as 
editing or file manipulation, in normal (fore- 
ground) mode. The 8560 supports two line- 
printer ports, allowing listings to be printed 
in background mode (otherwise known as 
lineprinter spooling) while users proceed to 
perform other tasks. By having two line- 
printer ports, users can access either high- 
speed/medium-quality, or low-speed/high- 
quality printers on the same system. Short 
printout jobs don’t have to await comple- 
tion of a lengthy printout, and printout 
quality does not have to be sacrificed. 
Background tasks also can be prioritized 
to minimize the impact of multitasking on 
other 8560 users. 


File management 

In a multi-user system, with source code 
or documentation shared by several users, 
file management is a critical element. The 
8560 uses a hierarchical file structure that 
permits multilevel directories and con- 
trolled access to files. Directories allow 

a user to quickly locate files of interest 
without having to peruse the entire list of 
files on the disk. 

Access to files is controlled by assign- 
ing each user a unique password. Three 
groups of users may access each file on 
the 8560. These include the owners of the 
file, members of the owner’s group, and 
all others. Each of these groups may be 


assigned read, write, and execute 
permission. 

Another important 8560 file manage- 
ment feature is the ability to link to files in 
other directories. The same information 
can be found under multiple directories, 
without requiring duplicate files. When a 
file is updated, the same information is 
available to someone accessing the file 
through a different directory. The need to 
recopy modified files is eliminated. 

The capability to directly execute, copy, 
or link to another’s file, with appropriate 
access control, contributes greatly to pro- 
ductivity in a multi-user environment. 


Automated build control 

In any major software development task, 
program management is critical. The large 
number of interdependent modules gener- 
ated by the design team must be com- 
bined without build errors. Build errors 
usually result from combining wrong mod- 
ules or wrong versions of the correct 
modules. 

The 8560 uses an automated approach 
to the build problem. Using a command 
called ‘‘make’’, programs can be auto- 
matically generated from only the most up- 
to-date source code. ‘‘Make’’ utilizes a de- 
scription file, which defines all intermodule 
dependencies, and associated commands 
to generate each module. Upon execution, 
“‘make’’ compares the modification date 
of an output module (i.e. an output file) 
with the appropriate input module (i.e. 
source code file). If the modification date 
of the input module is later than that of the 
output module, then the output file is re- 
created. This procedure greatly reduces 
the time needed to produce an executable 
program because it is no longer necessary 
to reassemble or recompile every module. 


Interuser communication 

Effective comunication between team 
members is essential for software develop- 
ment to proceed smoothly and with a mini- 
mum of problems. The 8560 takes an in- 
novative approach to interuser communi- 
cation. A command called ‘‘mail’”’ allows a 
user to send a message to another user 
and store it in a private mailbox for that 
user. If a user has mail, the system auto- 
matically notifies the user when he or she 
logs into the system. The mail can be 
quickly viewed and then either deleted or 
retained for future reference. A user can 
also use the mail system to receive notifi- 


cation when a spooled printer output is 
completed. 

Each user can determine who else is 
logged into the system and send a mes- 
sage directly to a user by executing the 
“write’’ command and referencing the 
user-identification. To avoid interruption of 
a Critical task, each user can decide 
whether or not to allow direct communica- 
tion. If necessary, a command requiring 
special authorization is provided to send a 
system message to all users regardless of 
messages being turned off. 

Users can also use the 8560’s docu- 
mentation tools with the mail system, to 
generate memos and so forth. 


Optional software expands capability 
TNIX includes several optional software 


packages that allow a user to add capabili- 


ty as needed. An auxiliary utilities pack- 
age, containing over 30 programs, en- 
hances operating flexibility. An ‘‘awk’’ 
command allows the user to search a file 
for a selected pattern and then execute a 
command upon its occurrence. This is a 
powerful tool for reducing data from the 
optional Trigger Trace Analyzer. Another 
command, ‘‘bc’’, provides a binary calcu- 
lator that lets the user enter arithmetic 
operations into the system and get results 
back with unlimited precision. This com- 
mand also performs base number conver- 
sions, such as binary to octal, hexadeci- 
mal, etc. Other programs in this package 
provide batch editing, general preproces- 
sing, and useful file manipulation. 

The documentation package is an- 
other extremely useful option. This pack- 
age greatly simplifies the many tasks in- 
volved with producing quality documenta- 
tion. For example, when text is entered in- 
to a file, formatting commands are includ- 
ed to generate the page layout desired. 
The resulting file is then passed to a for- 
matting utility that produces the document. 
To change the page layout, only the lines 
containing format commands need be 
changed. The formatting utility will auto- 
matically generate the revised layout. If 
the text is to be typeset, as for manuals 
production, the 8560 can generate output 
suitable for commercial phototypesetters. 

Other time-consuming tasks, such as 
table generation and typesetting of mathe- 
matical equations are efficiently handled 
by special commands. There are com- 
mands to look for spelling errors, generate 
a permuted index, and so forth. In addi- 


tion, special reports, manuals, business 
letters, specifications, and’other docu- 
ments can easily be created on the 8560. 
Users have complete control over para- 
graph justification, indentation, underlining, 
bold-facing, page headers and trailers, 
footnotes, and character fonts. These ‘‘ac- 
tive” documentation tools improve produc- 
tivity substantially. 

The optional native programming 
package contains 23 programs which pro- 
vide high level and assembly language 
support for the 8560. A C compiler can be 
used to develop utilities that will enhance 
8560 operation. Several supporting pro- 
grams simplify and extend the use of C. 

A “program beautifier’’ command will 
clarify program structure by indenting 
nested loops, procedures, and so forth. 

Programs to perform syntax checking 
and program linking are also provided. In 
addition, an assembler is included for de- 
veloping special purpose routines which 
can execute faster. 

BASIC, another high level language, is 
also provided for development of a variety 
of applications. 

The auxiliary utilities, text processing, 
and native programming packages are 
provided to allow the user to tailor the op- 
erating system to a particular need. As 
category C software, they carry a low 
priority for updating; however, these pack- 
ages have been under development for 
several years and typically are error-free. 


Summary 

A software development system should 
enhance individual and team efforts in pro- 
ducing a reliable, quality product. It should 
eliminate many of the tedious program- ° 
ming, documenting, and manual software 
management tasks that design teams 
encounter. 

The 8560 Multi-User Software Develop- 
ment Unit meets all of these requirements, 
and more. The innovative interuser com- 
munications system facilitates sharing of 
design information. A hierarchical file sys- 
tem with controlled access allows files to 
be organized and accessed in a manner 
that maximizes team productivity. Auto- 
matic build control and user-program- 
mable command files save hours of pro- 
cessing time and keyboard entry. And the 
companion 8540 Integration Unit allows 
software and hardware to be integrated 
in a controlled manner, with effective tools 


for rapidly isolating and resolving any 
problem that may exist. 

The TNIX operating system includes 
several commands designed to maximize 
efficiency when using the 8540 Integration 
Unit with the 8560. For example, the oper- 
ating system recognizes those commands 
that are uniquely 8540 and passes them 
directly to the 8540. The system also can 
selectively access up to eight 8540s con- 
nected to a single 8560. The following arti- 
cle discusses the 8540 Integration Unit. 
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A Powerful New Tool for 
Integrating Microcomputer 
Hardware and Software 


Figure 1. The 8540 Integration Unit, pictured with the CT8500 CRT Terminal and prototype 
control probe, provides complete coverage of the hardware/software integration process 
during microcomputer design. 


Integrating newly-written software and 
prototype hardware can easily consume 
as much time as writing the software 
itself. The new Tektronix 8540 Integration 
Unit turns this difficult task into an orderly, 
efficient process. 

The 8540, with an 8560 Multi-User Soft- 
ware Development Unit (or other host 
computer) and a system terminal, forms 
a complete microcomputer development 
system. The system provides a powerful 
set of tools for testing microcomputer pro- 
grams and prototype hardware, with full- 
emulation and PROM programming 
capabilities. 

Software is developed on the 8560 
(which also provides mass storage and file 
management) and then is downloaded to 
the 8540 via the built-in high-speed (153.6 
kilobaud) interface. 

For host computers other than the 
8560, an optional communication interface 
is available. The major interface parame- 
ters of this interface are software select- 
able through the 8540’s operating system, 
so the communications package can be 
tailored to individual host situations. 

Using commonly available RS-232-C 
ports and the optional communications in- 
terface package, the 8540 can be inter- 
faced to most host computers in a matter 
of minutes. All communications parame- 
ters, such as parity, echo, and turnaround 
delay, can be set directly from the 
keyboard. 

Three basic operating modes are avail- 
able. The object code transfer mode per- 
mits transferring object code modules be- 
tween the host and the 8540’s program 


memory, with full error checking and re- 
covery during the process. 

Terminal mode allows the user’s termi- 
nal to communicate directly with the host 
computer. The terminal is physically con- 
nected to the 8540; however, a single 
command routes the terminal directly to 
the host, making the 8540 transparent to 
the user. 

Loca! mode provides direct communica- 
tion between the terminal and the 8540, 
for controlling the emulation and debug- 
ging process. 


Emulator support 

The 8540 uses interchangeable emulator 
modules to allow you to configure the 
8540 to your application. The 8540 sup- 
ports both 8-bit and 16-bit microprocessors 
including those listed in Table |. 


Table 1 
Chips The 8540 I.U. Supports 

16-bit 8-bit 
Z8001 6809 8088 
Z8002 6800 8048 
8086 6808 8039 
68000 6802 8039-A 
TMS9900 Z80A 8035 
SBP9900 8080A 8021 
SBP9989 8085A 8022 

8049 8041A 


Using an emulator processor identical 
to that targeted for the prototype, the 8540 
provides real-time emulation. This means 
that the prototype code can be executed 
at the specified operating speed of the 
target processor, while under control of 
the 8540’s debug system. 


Three modes of real-time emulation 
Emulation takes place in three progressive 
modes that allow gradual introduction of 
hardware and software. In mode 0 (system 
mode), the software is executed on the 
8540's emulator processor. Program input 
and output can be simulated using system 
resources in the console display, key- 
board, or 8560 file system. Thus, you can 
begin debugging your program before the 
prototype hardware is available, or con- 
tinue debugging should the hardware be- 
come inoperable. 

In the next phase, Mode 1, the 8540 
emulator connects directly to the proto- 
type hardware via the prototype control 
probe. In this mode, the program resides 
in 8540 memory and can be transferred to 
prototype memory in sections as small as 
128 bytes. This technique, called mapping, 
allows the program to be gradually trans- 
ferred into the prototype on a step-by-step 
basis. The program can interact with pro- 
totype I/O, development system 1/O, or 
both. 

In Mode 2, all of the code resides in the 
prototype memory. This mode is used to 
make a final check with the actual proto- 
type memory devices (such as ROM or 
PROM) in place. The control probe re- 
mains in the microprocessor socket on the 
prototype to provide continual debugging 
control during program execution. 

During all three modes of emulation, 
prototype code execution is under control 
of the 8540’s powerful debug software. 
For easy reference, key breakpoints may 
be entered using mnemonic labels (sym- 
bols) instead of numeric addresses. At 
each breakpoint, the status of all of the 
processor's key registers, flags, and status 
bits is displayed. You can also display the 
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processor’s register status and associated 
code execution on a cycle-by-cycle basis. 
Any register or memory location can be 
modified right from the keyboard. 

The 8540 debug commands are inte- 
grated into TNIX, the 8560 Software Devel- 
opment Unit’s operating system, so the 
user can control both 8540 and 8560 re- 
sources with a unified, compatible syntax. 
This capability also allows the 8540 to use 
8560 resources, such as file I/O and data 
reduction, to enhance the debugging 
operation. 


Trigger trace analyzer 

Many debugging situations require detailed 
analysis of real-time code execution and 
the effect on other key points in the hard- 
ware. The trigger trace analyzer (TTA), a 
modular option to the 8540, provides a 
complete facility to acquire real-time data 
in both 8-bit and 16-bit processor-based 
systems. Up to 255 bus transactions oc- 
curring before, during, or after a specified 
event can be captured. An 8-channel data 
acquisition probe allows you to select and 
monitor up to eight points in the prototype 
hardware. For further details on the trigger 
trace analyzer see the article commencing 
on page 12. 


System overview 

The 8540 operating system (OS/40) is simi- 
lar to DOS/50 Version 2, the operating sys- 
tem developed for the 8550 Microcomput- 
er Development Lab'. A few commands 
are different, but the key difference is that 
commands execute much faster in the 
8540 as they are stored in PROM memory 
rather than on disk. 
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A functional block diagram of the 8540 
is shown in figure 2. A dual-processor ar- 
chitecture (in a master/slave arrangement) 
enables the 8540 to support several differ- 
ent microprocessors, using the same oper- 
ating system. In this configuration, the sys- 
tem processor serves as the master, and 
the emulator processor as the slave. The 
system processor and emulator processor 
have completely separate memory space 
so that system program and user (proto- 
type) programs do not conflict. 

The 8540 contains a 100-line system 
bus structure that provides most of the 
connections to the plug-in modules and 
options housed in the mainframe. The em- 
ulator controller board separates those 
control and signal lines that are dedicated 
to either the system section or the pro- 
gram section. Both the system processor 
and emulator processor share the basic 
bus structure, with the emulator controller 
serving as arbiter under the direction of 
the system processor. 

The system processor resides on the 
system controller board and provides over- 
all control of the 8540. It directs all I/O ac- 
tivity for the system peripherals, performs 
all system utility functions, and executes 
the debug program—controlling the emu- 
lator processor through separate debug 
hardware. 

To allow you to configure the 8540 for 
your specific application, the emulator pro- 
cessors are designed as plug-in modules 
and assigned option status. An emulator 
option includes both hardware and sofft- 
ware for the target microprocessor or 
microcomputer. The emulator processor 
interfaces with the prototype hardware via 
a prototype control probe. Advanced probe 
design makes the emulator processor 
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Figure 2. Functional block diagram of the 8540. A wide selection of options allow you to configure the 8540 to your design needs. 
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Figure 3. Emulators and prototype control probes for the 8540 feature state-of-the-art 
design that allows your programs to run at the full operating speed of the target 
microprocessor. 


practically transparent to the prototype 
and allows prototype code to be executed 
at the full operating speed of the target 
processor, without adding wait states or 
stretching clock pulses (see figure 3). 


Versatile memory manipulation 

Memory in the 8540 consists of two major 
sections—system memory and program 
memory. System memory includes 240K 
bytes of ROM, which contain the operating 
system and software for optional equip- 
ment. Also resident on the ROM board are 
4K bytes of EEPROM used for updating 
the operating system and for storing 
unique user-developed command strings. 
The contents of the EEPROM can be 
changed from the system terminal 
keyboard. 

The operating system is loaded from 
system ROM and executed in the 64K-byte 
system RAM. User symbol! table informa- 
tion employed in symbolic debugging is 
also stored in system RAM. 

Program (emulator) memory consists of 
32K bytes of static RAM, optionally ex- 
pandable to 256K bytes. It is used for stor- 
ing prototype code downloaded from the 
8560 or the host computer. 

The system processor has control of 
both system memory and program memo- 
ry. As previously mentioned, in emulation 
mode 1, program memory can be mapped 
into prototype memory in 128-byte blocks, 


allowing orderly transfer of proven pro- 
gram segments to the prototype. 

When working with devices such as the 
Z8001/Z8002, 68000, and 8086, whose ad- 
dressing capabilities exceed the 8540's 
program memory, the Memory Allocation 
Controller (optional with the Z8001/2 and 
68000 emulators) can be used to allocate 
program memory in 4K-byte blocks over 
an address space of up to 64M bytes. 


PROM programming 

Once the prototype code is debugged, it 
can be put into firmware using the optional 
PROM programmer available for the 8540. 
The PROM programmer consists of a con- 
troller board, front-panel assembly, and a 
characteristic module to adapt the pro- 
grammer to whatever PROM family you re- 
quire. The 8540 currently supports 2716, 
2732, 8748, 8741A, and 8755 PROMs. 


System diagnostics 

When attempting to integrate software and 
prototype hardware, it is essential to know 
that your integration tools are working pro- 
perly. The 8540 has two resident diagnos- 
tic test programs for verifying system 
operation. 

The power-up diagnostic tests are run 
automatically during power-up or restart 
conditions. These tests verify the circuitry 
within the 8540 that is required to boot 
and transfer the operating system from 
ROM into the 8540’s system memory. 


Should a fault occur that prevents the 
operating system from booting or prohibits 
ROM-resident diagnostics from running, a 
program called Critical Function Monitor 
(CFM) is automatically entered. The CFM 
contains several test routines and a limited 
set of user commands that are entered 
from the system terminal. This program, in 
conjunction with a series of LEDs located 
on the system controller and system RAM 
boards, will usually isolate the source of 
trouble. 

The ROM-resident diagnostics provide a 
means of verifying system performance, 
and a tool for troubleshooting in the event 
that a failure is detected during the run- 
ning of a test. The menu-driven diagnostics 
are easy to use, and run automatically 
after being initiated by the user. 


Summary 

The 8540 Integration Unit is designed to 
help you accomplish the entire software/ 
hardware integration process in an orderly, 
efficient manner. The 8540 can be easily 
interfaced to most host computers or any 
of the 8000 Series of Tektronix microcom- 
puter development units, such as the 
8560, 8550, and 8001. State-of-the-art 
emulators allow your programs to run at 
full speed, while the advanced trigger 
trace analyzer captures up to 255 bus 
transactions and select logic operations 
for analysis. The 8540 supports most pop- 
ular 8- and 16-bit microprocessors and 
microcomputers. 
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A New Real-Time Debugging 
Tool for the 8500 Series MDL 


The Trigger Trace Analyzer (TTA) is a mod- 
ular option for the 8540 and 8550 that al- 
lows you to monitor the buses and select- 
ed control signals in prototype hardware, 
while your program executes at normal 
speed. The TTA provides precise control 
of the selection of data to be stored and 
analyzed. Up to 255 bus transactions and 
logic signals from various points on the 
prototype can be captured and stored in 
the TTA’s acquisition memory and dis- 
played for analysis. 

The TTA monitors 64 bits of information 
that you can select in any combination 
(using software commands) to define a 
trigger signal for acquiring data or for 
other purposes. The 64 bits of informa- 
tion monitored include: 

e the address bus (up to 24 bits) 

e the data bus (8 or 16 bits) 

e the data acquisition probe (8 bits) 

e the emulator-dependent bus signal 
interface (up to 11 bits) 

e the external event qualifier (1 bit) 

e counter output signals (4 bits) 

All of these signals are input to an event 
comparator, which functions as a word 


Figure 1. The Trigger Trace Analyzer option includes two plug-in modules, bus intercon- 
necting cables, an 8-channel signal acquisition probe, and an interface panel that includes 
the four trigger channel outputs. 


12 


recognizer (see figure 2). The output of the 
event comparator is ANDed with the out- 
put of a programmable general-purpose 
counter, to generate a trigger signal. There 
are four such trigger channels in the TTA. 
These triggers can be used independently 
or interactively to construct a powerful 
data acquisition trigger. The outputs of the 
four trigger channels also are available ex- 
ternally (via BNC connectors on the TTA 
interface panel) for triggering external 
equipment. 


Defining an event 
To better comprehend the flexibility the 
TTA offers in defining a trigger point, let’s 
consider some of the event control com- 
mands used to specify which input data 
constitutes an event. There is a separate 
command for each of the event compara- 
tor input sources. There is also one com- 
mand that you can use to specify all in- 
puts—the ‘‘eve’’ command. The ‘‘ad” 
command is used to define a specific ad- 
dress or range of addresses as an event. 
The commands 

ad 1 105E 

ad 2 500 530 
specify that event 1 occurs whenever the 
program accesses address 105E, and that 
event 2 occurs whenever the program ac- 
cesses an address within the range 500 to 
530, inclusive. The “‘ad’’ command can in- 
clude a ‘‘-n’”’ command modifier that de- 
fines the event as anything other than the 
value specified. For example, 

ad -n 4 1000 10FF 
defines event 4 as any address outside the 
range 1000 to 10FF. 

Another event command, ‘‘ctr’’, defines 
an event as a pattern of the outputs of the 
four counters associated with the event 
comparators. The pattern can include 1’s, 
0’s, or X’s (don’t cares). For example, the 
command 

ctr 1 10X0 
causes event 1 to occur when counter 1 
is high and counters 2 and 4 are low. 

In addition to triggering on individual 
events, it is possible to trigger on the oc- 
currence of multiple events. By using the 
“cons” command, events can be linked 
together so that the occurrence of one 
event arms the comparator of the follow- 
ing event. All of the events within a se- 
quence must occur on consecutive cycles 
of the specified type. The ‘“‘cons’’ com- 
mand requires you to select one bus 


EVENT 
COMPARATOR 


GENERAL 
PURPOSE 
COUNTER 


Figure 2. Each trigger channel has its own 64-input event comparator and programmable 
general-purpose counter. You can select from several event control commands to specify 
which input data constitutes an event. The four trigger channels can be linked together to 


provide almost unlimited trigger selections. 


mode in which all of the events are con- 
sidered. The bus modes are: cyc—all bus 


cycles are allowed; fet—only fetch cycles * 


are considered; and emu—only emulator- 
dependent bus cycles are considered. 


The general-purpose counters 

We discussed, previously, the ability to 
specify the output of the four general- 
purpose counters as inputs to the event 
counter, to construct an event. The 
counters also can be used singly or 
together for other purposes. Let’s take 
a look at their capability. 

The ‘‘cou’’ command defines the 
counter operation. This command selects 
a value to be counted, a source that is 
counted, a gate signal that will enable or 
disable the counting process, and the kind 
of signal that will be output when the 
counting operation is completed. For 
example, 

cou2v=4 s=ev1l o=delay 
programs counter 2 to be asserted after 
the fourth occurrence of event 1. 

The “‘v” or value parameter may be set 
anywhere between 1 and 65,536, with the 
value assumed to be decimal unless spec- 
ified otherwise. 

The source parameter, ‘‘s’’, options in- 
clude counting of: clock intervals from 
200 ns to 2 ms in decimal steps; occur- 
rences of event signals for channel 1, 2, 3, 
or 4; occurrences of trigger signals for 
channel 1, 2, 3, or 4; the number of bus 
transactions; the number of emulator 
cycles; the emulator’s clock signal; and 
the event qualifier signal. Only one of the 
latter three may be selected at one time. 
However, each of the four counters may 
operate on the selected signal. 


A gate parameter, ‘‘g’’, places a restric- 
tion on the indicated counter and specifies 
those conditions during which the counter 
may count. Most of the conditions involve 
the output state of the next lower number 
counter, so the “gate’’ parameter is only 
valid for counters 2, 3, and 4. 

The “restart” parameter allows you to 
have the counter reloaded with its initial 
“value” when the ‘‘gate’’ source is as- 
serted. The options are ON and OFF. 

The last counter parameter to be con- 
sidered is ‘“‘output’’. As the name implies, 
this parameter controls the output of the 
counter. There are five options: when 
“arm’’ is specified, the counter output re- 
mains high; ‘‘disarm’’—the output re- 
mains low. When “pulse” is specified, the 
counter output is low, pulses high when 
counting is complete, then goes low again. 
In ‘‘delay”’, the output is initially low, and 
goes high after counting is complete. 
“timeout” produces the reverse of 
“delay’’. 


The breakpoint command 

The breakpoint command controls the ef- 
fects of an event’s trigger signal. For each 
trigger, this command can set a break- 
point, clear a breakpoint, and enable or 
disable the ‘‘continue”’ function. 

The breakpoint, if enabled, causes a 
program to halt execution when an event 
and its associated trigger signal occur. A 
trace line is displayed on the system ter- 
minal and control is returned to the oper- 
ating system. The “‘cont’’ function, if en- 
abled, interrupts the program when the 
event and its trigger signal occur, and a 
trace is displayed. However, control is re- 
turned to the program, which continues 
execution at full speed. 


The breakpoint parameters ‘‘stop’’ and 
“cont” can be set as a parameter in most 
of the event and counter commands. 


The acquisition memory 

Now that we have discussed how thor- 
oughly we can define when data will be 
captured, let’s look at what data can be 
captured. The acquisition memory is a 
255-by-62-bit buffer. The input data avail- 
able for storage includes that monitored 
by the event comparators with the excep- 
tion of the counter outputs (see figure 3). 

The “acq’”’ command specifies what 
data is to be stored when the trigger sig- 
nal occurs. ‘‘acq all’’ stores all of the 
most recent 255 bus transactions, which 
can include the eight inputs from the 
P6451 data acquisition probe. ‘‘acq ev4’’ 
stores only those transactions defined as 
event 4. A parameter called ‘for expres- 
sion source” allows you to specify acqui- 
sitions at some point other than the end of 
a program. The expression must evaluate 
to some number between 1 and 65536. 
The source portion of this parameter iden- 
tifies a specific kind of bus transaction, 
with the options available identical to the 
source parameters used with the ‘‘cou”’ 
command. An “‘aftertrig 4’’ parameter 
disables the counting of the source until 
trigger 4 occurs. 

A typical acquisition command may ap- 
pear as this: 

acq all for 10 cyc aftertrig4 
which would store all bus transactions un- 
til the occurrence of the tenth cycle after 
the occurrence of trigger 4. 

The display command, “‘disp’’, allows 
you to select the portion of acquisition 
memory to be displayed on the system ter- 
minal. You may display all of the bus tran- 
sactions stored, or display only some 
number of transactions you want to see. 

The information displayed when you 
enter the display command includes an 
address, data, an opcode mnemonic, the 
states of the eight data acquisition probe 
signals, and symbols representing the type 
of bus operations that occurred. 


A typical application 

Now let’s consider a typical application 
that involves using two channels of the 
TTA. j 

Problem: Provide timing for an interrupt 
routine located at 1000H to 1024H. 
Solution: Trigger channel one is used to 
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Figure 3. The acquisition memory is similar to the buffer memory of a logic analyzer. This 
figure shows the contents of the acquisition memory after 265 samples of input data have 
been taken. Only the most recent 255 samples are retained. 


detect the start of the interrupt routine and 
activate channel two’s counter. When the 
interrupt routine is completed, channel 
two’s word recognizer is used to stop the 
counter. The following command se- 
quence is entered: 

ad 1 1000 

ad 2 1024 

cou 2 v=0 s=200NSEC 0o=ARM 

g =SEQH-s 
Where: ad 1000 enters the hexadecimal 
value 1000 into the address portion of the 
channel one word recognizer. 
ad 1024 enters 1024H into the channel 
two word recognizer 
cou 2 selects the channel two counter 
v=0 puts the channel two counter’s initial 
value at zero 
S=200NSEC selects 200 nanoseconds as 
the counting unit 
o=ARNM sets up EVENT 2 to cause the 
breakpoint 
g=SEQH selects channel one’s trigger 
output as the source that will enable the 
counter 
-S indicates that a breakpoint will occur 
when the channel two trigger goes active 

This command sequence produces a 

channel one trigger at the start of the in- 
terrupt routine, 1000H. This trigger then 
activates the channel two counter which 
begins counting in 200 nanosecond incre- 
ments. Channel two’s word recognizer 
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produces a trigger when the interrupt 
routine is completed at 1024H. This sec- 
ond trigger causes a breakpoint to occur 
that automatically stops the counter. The 
resulting counter value is then read by 
calling up the trigger status display, which 
will show the counter’s value at the time 
of the breakpoint. 


Conclusion 

The trigger trace analyzer option for the 
8540 and 8550 is a powerful real-time 
debugging tool. You have almost unlimited 
capability to specify the trigger conditions 
for acquiring data while your program ex- 
ecutes at full speed. Bus transactions, plus 
logic states from eight selected points in 
the prototype hardware, can be captured 
and stored for analysis. The TTA is a valu- 
able adjunct to the 8540 and 8550 in facili- 
tating software and hardware prototype 
integration. 


